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10 ELECTRONIC PAYMENT SYSTEM UTILIZING 
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^Ma! This application is^a continuation of U.S. Provisional Application 

:1J 15 No. 60/108,762 filed November 17, 1998 and is a continuation of U.S. Provisional 
Application No. 60/141,994 filed July 1, 1999; both prior applications are hereby 
incorporated by reference. Applicant claims, as to both prior applications, the right 
r|| of priority pursuant to the Paris Convention and 35 USC § 119. 

O 20 Technical Field 

The present invention relates to methods and apparatus for making payments 
for the purchase of goods or services. Specifically, the invention provides for 
receiving payments in cash or by other means, at any of a number of convenient 
locations, such as merchant point-of-sale locations, and includes means for 
25 electronically crediting a selected end-user account in response to the payment. An 
intermediate account is provided in between the payment side and the vendor account 
side, offering advantages in terms of performance, accounting, credit risk allocation, 
convenience and user anonymity. 

30 Background of the Invention 

Various means are known for paying for goods or services, the most 
fundamental method being payment in cash at the time and place of the purchase. 


V 
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Credit cards and debit cards are widely used for convenience in making purchases as 
the user need not carry cash and risk losing it or having it stolen. Credit card 
accounts also are used to extend credit to a user or cardholder, although card issuers 
are known to suffer substantial credit losses. One way for vendors of goods or 
5 services to avoid credit losses and reduce collection problems is to establish 

"pre-paid" accounts. A pre-paid account, as the name implies, requires that the user 
pay for selected goods or services in advance; subsequent delivery of the goods or 
services is charged against the pre-paid account by debiting the user's balance. The 
problem here is that adding value to or "recharging" pre-paid vendor accounts is not 

10 convenient. 

Pre-paid wireless (cell phone) service provides an illustrative example. 
Pre-paid wireless service enables customers to utilize the convenience of cellular and 
digital communications by establishing a prepaid account with a wireless 
telecommunications vendor. Typically, prepaid wireless cards, each card 

1 5 corresponding to a wireless services account, are purchased in preset denominations 
in a limited number of locations. The cards are issued in fixed value increments, for 
example, $20, $50 or $100. Each card provides the end-user with a specified amount 
of wireless calling dollars or minutes. After the initial allocation is exhausted (or 
before), the user can "recharge" or reload their wireless account usually by calling an 

20 800 number, having a credit card handy, and either talking with a customer service 

representative (CSR) or using an automated system to charge additional minutes to the 
credit card. This system is burdensome to both the user and the wireless carrier. 
Moreover, some users have pre-paid wireless accounts because of credit problems 
and thus may not have a valid credit card available for this purpose. 

25 A new method for affecting payment for wireless telecommunications 

services, as well as other goods and services, is needed that enables a customer to 
purchase variable amounts of value for loading onto the customer's account. A new 
system should allow making such payments at convenient locations. And a new 
payment system should allow a user to affect bill payment or otherwise purchase 

30 goods and services, for example from a remote vendor, without the need to establish 
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good credit in advance. It is also desirable that a payment system provide anonymity 
especially for dealing with remote vendors, yet physical separation of purchaser and 
vendor, the "card holder not present" scenario, is known to contribute to credit card 
fraud losses. The use of cash addresses some of these problems, but it is not practical 
5 for remote vendors. 

Summary of the Invention 

A primary aspect of the present invention is directed to providing a stored 
value intermediary account to implement a centralized payment system. The 

10 centralized payment system interfaces with merchant points-of-sale where cash 

payments (or other forms of payments) are received from the end-user (or his agent). 
The present invention leverages the existing financial network that is used around the 
world for credit card transactions, but it uses that existing system "backwards" in that 
payments are received , rather than credit extended, at the merchant point-of-sale. 

15 Interfacing to the existing world-wide network, e.g. VisaNet or another card 
association network, in this new way allows payments to be received at any of 
literally millions of merchant locations that are coupled to the network, thus 
providing extraordinary convenience for the end-user. The payments are posted to an 
intermediary account maintained on the centralized payment system. Thus an 

20 important feature of the present invention is the use of a ubiquitous standards-based 

electronic system for recharging (adding value to) end-user accounts from retail point- 
of-sale terminals. 

Another aspect of the invention focuses on the payment side of the system; 
namely, effecting an electronic payment from the central intermediary account to a 
25 wireless carrier or other vendor on behalf of the end-user. A further advantage in 
this regard is security and anonymity because no personal information about the end- 
user, not even the user's name, need be stored in the central intermediary payment 
system. 

Additional objects and advantages of this invention will be apparent from the 
30 following detailed description of preferred embodiments thereof which proceeds with 
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reference to the accompanying drawings. In the detailed description, we use wireless 
services as an example of goods or services that can be paid for using the new 
centralized payment system. Wireless services are merely illustrative and are used as 
a convenient way to describe the invention; it can be used to pay for any goods or 
5 services. 


Brief Description of the Drawings 

The foregoing aspects and the attendant advantages of this invention will 
become more readily appreciated through reference to the following detailed 
10 description, when read and considered in conjunction with the accompanying 
drawings, wherein: 

u] Fig.l is a block diagram introducing the various components involved in the 

; s |* system and methods of the present invention. 

[ 3f Fig. 2 is a flow chart illustrating a method for processing the recharge of an 

53 15 end-user account maintained on a prepaid platform, utilizing an intermediary payment 

\m processor system according to the invention. 

| =: " Fig. 3 is a flow chart illustrating a method for establishing account and 

CM:!! processing customer inquiries through^feGasfe Customer Care Services. 

Fig. 4 is a flow chart illustrating a method for reversing unauthorized or 
20 improperly processed transactions. 

Fig. 5 is a flow chart illustrating a method for the financial settlement and 
clearing of payments made by the PreCash card user for wireless telecommunications 
services. 

Fig. 6 is a flow chart illustrating a method for reporting the daily and monthly 
25 activity of the end-user, the merchant and the wireless carrier. 

Fig. 7 is a flow chart illustrating a method for the ordering, production and 
o— ' distribution of tlie$*^t^^ 

A 

Fig. 8 is a block diagram illustrating the components involved in the 
ry communications between a customer, a merchant, -PreCaGh and a--fnternet- merchant. 
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Fig. 9 is a series of flow charts illustrating a method for communicating the 
recharge and authorization request to the PreGasfr processor. 
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Detailed Description of a Preferred Embodiment 

Figure 1 illustrates the principle components of a system and methods 
according to the present invention to provide payment and related functionality for the 
5 purchase of wireless telecommunications services and other pre-paid goods and 

services. Referring to Figure 1, a card user 20 represents a person who has or will 
establish one or more payment accounts according the invention. Card user 20 is 
illustrated as visiting at a point-of-sale. A point-of-sale can be a conventional "brick 
and mortar" retail merchant location, such as a store or restaurant. A point-of-sale 
10 for present purposes can also be an automated teller machine (ATM), a kiosk, touch- 
screen or other data terminal as further described herein at any location accessible to 
users. 

In Figure 1 , the merchant 30 refers generically to the proprietor of a point-of- 
sale establishment, such as a convenience store or other merchant location. In 

15 general, merchant 30 refers an establishment where one or more point-of-sale 

terminals are installed so as to provide access to a financial network. For example, 
millions of retail establishments around the world today have installed small data 
terminals which are coupled to a financial network for communicating financial 
transaction information, either using a dial up modem or dedicated line. Typically, 

20 these terminals include a card reader that enables a merchant's employee to "swipe" a 
credit card whereupon the card reader reads the credit card account number for 
transmission over the financial network as part of a credit (or debit) card purchase 
transaction. According to the present invention, as further described later, the same 
type of terminal can be used instead to facilitate a payment transaction in which the 

25 cardholder delivers cash or other payment to the merchant at the point-of-sale for the 
purpose of "recharging" or adding value to an associated user account, for example a 
wireless carrier prepaid platform 112. 

The heart of the present system is a payment processor 40, which can be 
conveniently implemented on a suitable general purpose digital computer programmed 

30 as explained in greater detail later. The. principle features and functions of the 
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payment processor, each of which will be described in greater detail in turn, include a 
means 50 for accessing an existing financial network to communicate financial 
transaction data; account activation services 60 for activating and maintaining 
intermediary accounts on the payment processor system; payment customer care 
5 services 70; payment clearing, settlement and reporting services 80; payment card 
production and management services 90 and means 100 for interfacing the payment 
processor system to a customer such as a wireless carrier prepaid platform 112. 

It is critical to note that in this application, the cardholder or card user 20 is an 
individual (or business) who utilizes goods or services provided by a vendor such as 
10 the wireless carrier 110/112. The user account, which we also refer to as the end- 
>Is user account, is maintained by the vendor such as the wireless carrier 110 on the 

Li J vendor's prepaid platform 112. The end-user is not referred herein as a "customer." 

1i Rather, the "customer" of the present payment system is the provider of goods or 

services, such as wireless telecommunications services carrier 110, who, again, 
a 15 provides goods or services to the end-user. That vendor is a "customer" of the 

nj present payment system. The system is intended to serve the needs of multiple 

[ ~ customers (each of which has its own universe of end-users). One important feature 

! «f of the present system is that the customer interface 100 provides a standardized 

interface to enable numerous^ esp e ra te "customers" to take advantage of the present 
20 system, providing a highly effective real time cost-efficient method for their end-users 
to pay for goods and services. The payment processor 40 maintains a database of 
cardholder accounts, each of which is "associated" with a corresponding "customer" 
or vendor end-user account, as further explained below. 

Figure 2 is a flow chart illustrating the basic method for processing a recharge 
25 transaction to add value to an end-user account maintained on a prepaid platform. We 
use prepaid wireless services as an illustrative example of a customer/ vendor. The 
payment card user 20 visits a merchant of point-of-sale location where a point-of-sale 
terminal 32 is installed. The card user makes a payment to the merchant, for example 
in cash, and presents the user's account identifier. This refers to the intermediary 
30 account which is maintained on the pre-payment processor 40. It is not the same as 
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the end-user account which would be maintained at the carrier's prepaid platform 
112. The card user can present the intermediary account number by providing a 
physical card, in which case the merchant can swipe the card in the typical point-of- 
sale terminal to read the account number. Alternatively, it can be keyed into the POS 
5 terminal manually. The merchant also keys in the dollar amount of the payment and 
presses a key or a predetermined code to initiate an authorization request. 

The payment to the merchant need not necessarily be made in cash. For 
example, the payment could be made using a credit card or a debit card. In that case, 
the same POS terminal 32 can be used in the conventional manner to effect the credit 
10 or debit card transaction. However the payment might have been received, the 
uSi merchant then indicates the amount of the payment, as noted, and transmits through 

i /t the terminal an authorization request 54 into the financial network 52. Financial 

| U network 52 corresponds to any of the existing card association networks currently in 

! jj I use, for example the VisaNet network. The POS terminal 32 can be directly 

15 connected to the financial network, or a plurality of individual terminals are 
ni sometimes congregated through a merchant hub (not shown), which in turn is 

f7 communicates with the financial network. Various architectures for this connection 

□ are known in the prior art. It is also common for one or more point-of-sale terminals 

to be networked or otherwise coupled to a merchant host computer at the retail 
20 location. In addition, it is generally the case that the point-of-sale terminal (or 
merchant host/hub) communicate with an "acquiring processor" which in turn 
communicates to the card association network (52 in Fig. 2). The present invention 
can be used over any of these network arrangements, as illustrated in Figure44: 
In all cases, the authorization request message is routed to the payment 
25 processor 40 by using a bank identification number (BIN) that corresponds to the 
payment processor 40. The BIN is a 6-digit series of numbers that is used by bank 
card companies to identify their financial transactions. For example, American 
Express* (AmEx) range is 3xxxxx; Visa's range is 4xxxxx and MasterCard is 
5xxxxx. A range of numbers is assigned to the processor of the present invention so 
30 that it appears to the financial services network as if it were a credit card issuer. 
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Thus every intermediary account identifier maintained by the payment processor 40 
includes a BIN for routing communications over the existing financial network to the 
processor. The processor 40 receives the transaction, processes it, and transmits an 
approval or denial message 56 via the financial network 52 through connection 57 
5 back to the POS terminal 32. Assuming that the transaction is approved, the POS 

terminal can print a receipt and optionally print a duplicate - one for the card user and 
one for the merchant. These types of transactions traverse the existing financial 
network without difficulty because the card number and the transaction messages 
(e.g. authorization request/approval/denial) conform to bank card industry standards 

10 and protocols. A principle advantage of the present invention is that it leverages the 
worldwide existing financial network by using it for a new purpose and in a new way. 
Thus the functionality and features of the invention become available to users 
worldwide at minimal cost of implementation. 

After the payment transaction between the payment processor 40 and the 

15 point-of-sale terminal 32 is completed, the processor 40 then provides a load 

notification signal 114 to the carrier prepaid platform 112. This load notification 
identifies the end-user account that corresponds to (having been previously associated 
with) the intermediary account number presented by the card user at the point-of-sale. 
The load notification message 114 also includes an amount by which the end-user 

20 account should be credited or "recharged." This amount is not necessarily the same 
as the amount of the payment made by the card user to the merchant, depending upon 
various fees, discounts, or promotional programs that may apply. In the case of 
telecom services, the credit may be denominated in air minutes rather than dollars. 
All of these considerations and options can be taken into account through suitable 

25 programming in the processor 40. The processor 40 preferably is coupled to the 

customer site, for example a carrier prepaid platform 112, via a high bandwidth data 
communications link, such as frame relay connection, to minimize delay. 
Accordingly, the end-user account is recharged in nearly "real time" after payment at 
the merchant point-of-sale. Thus, in the case of prepaid wireless services, where the 

30 cardholder's wireless account has been exhausted, that account will be "recharged" 
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and telecommunication services available within seconds after payment is tendered to 
the merchant. The "check in the mail" delay is eliminated. 

Figure 3 is a flow chart illustrating methods for establishing an intermediary 
account and providing certain customer care services. To begin, a payment card user 
22 contacts a payment account assistance module 78, which can be implemented as 
part of customer care services software 70 on the payment processor system 40 or on 
another platform that can communicate with the processor. The account assistance 
software can be implemented, for example, using interactive voice recognition (TVR) 
technology, which is commercially available. This customer service application 78 is 
accessed by the card user in order to activate his or her account, by associating the 
intermediary account (card number) with an end-user account that is maintained by a 
payment customer such as a wireless carrier prepaid platform 112. The card user 
accesses the customer service application 78 and is prompted to identify the customer 
(carrier) and/or the end-user account number. (The user account number often can be 
used to identify the carrier.) The customer service application 70 communicates with 
the prepaid platform 112 to confirm or validate the account number provided by the 
card user. Assuming that the account information is valid, the customer care services 
70 then initiates account activation on the processor 40. Specifically, an account 
activation operation has the effect of associating the card number (the intermediary 
account identifier) with a selected prepaid platform (or other vendor) end-user 
account number. This association is reflected in an intermediary account database *iX 
maintained by the payment processor 40. There is no necessity for the processor 
database to contain any personal information about the card user; it need not even 
include the card user's name. However, steps can be taken to provide security in 
order to prevent, for example, an unauthorized person from changing the association 
of an intermediary account from one vendor to another. 

If the card user experiences difficulty in using the account assistance 
module 78 or simply prefers to talk with a live operator, they have the option to press 
zero, for example, to connect to a live operator 120. Alternatively, card user 22 can 
directly contact -the a customer service representative 120 at any time they wish to do 
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so. In Figure 3, the CSR 120 is a customer service representative of the vendor, for 
example the wireless services carrier (110 in Fig. 1) that is affiliated with the prepaid 
platform 112. The payment system customer care services 70 provides support to the 
carrier CSR 120 so that a customer service representative can conduct account 
5 activation and inquiries to the processor database. Preferably, the customer care 
services are provided through a customer care web server interface 72. The web 
server is non public. Rather, it is dedicated to providing a convenient interface to the 
carrier CSR through a customer care browser 122 executing on the carrier CSR's 
computer. The carrier (or other customer CSR) has only limited access and 

10 privileges on the processor system 40, as necessary to provide customer service to 
card users. For example, the carrier CSR would not be able to effect the equivalent 
of a payment transaction as that can be done only by a merchant as described above. 

Figure 4 illustrates additional features of the payment customer care services 
application 70. Here, the customer care services include providing support to a 

15 merchant support operator 34. The point-of-sale merchant 30 contacts a merchant 
support operator 34 in the event that a load reversal transaction becomes necessary, 
for example, where a payment transaction was effected an error. The customer care 
services application 70 provides an interactive interface to the processor 40, which 
can be accessed by the merchant support operator 34. In a presently preferred 

20 embodiment, the customer care services includes a customer care web server 

application 72 so that the merchant support operator can conveniently access the 
processor through a customer care browser interface 36, such as a commercially 
available web browser operable on a personal computer. This way no special 
equipment is needed to provide quality support to participating merchants. 


25 


Customer Interface 

Referring once again to Figure 1, it shows a customer interface 100 for 


interfacing the processor to the customer platform. The reader is reminded that, 
throughout this document, "customer" refers to the payment processing ^y s temfls 
30 customer, whereas "end-user" refers to the cardholder, which is to say the person 


Portlnd2-4227043vl 0029279-00003 



12 


that uses goods or services sold by the "customer." At least three transaction types 
are supported by the payment system customer interface: Account loading 
(charge/recharge), Account validation, and Load reversal. 

Below is a description of each of the three transaction types and the payment 
5 processing that is associated with them. 

1 • Account loading . Account loading (aka account recharge) is a 
transaction which uses the payment card to add value to the end-user's account as it is 
stored at the customer database. Upon receipt of an account loading transaction, the 
payment system performs a series of verifications to determine if the transaction is 
10 valid. These verifications can include, for example, authentication of the payment 
account, assessing transactional velocity and limits, validation of merchant, and 
detection of duplicate transactions. 

If the transaction passes the validation checks then the payment processor -and- 
prepares the transaction for remote processing at the customer processor. The 
1 5 payment system identifies the customer, the customer platform, and the end-user 
account number based on the payment account number. 

2. Account validation . Account validation is a transaction to verify that 
an end-user account number (e.g. a cell phone number) exists in the customer 
database. This transaction is performed when the end-user account number is being 

20 associated with the payment system (intermediary) account number. This transaction 
can be managed by either an interactive voice response (IVR) application that is 
running on a voice response unit (VRU) or through a live customer care 
representative accessing the PreCash processor through a web browser and a web 
server, as described above with reference to Figure 3. Typically this transaction will 

25 occur only once per payment card (account) and only once per end-user. 

3. Load reversal . Load reversal is a transaction to reverse the effects of a 
previously processed account loading transaction. This transaction is not designed to 
merely remove value from the balance associated with the end-user's account but to 
do so only to turn back the effects of an identified loading transaction that was 

30 previously processed against that account. Other requirements of this transaction type 
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include that the load reversal must occur on the same day as the original account load 
transaction and the end-user account must have enough of a balance that the reversal 
amount can be subtracted from it. This transaction will be managed by a live 
customer care representative accessing the payment processor through a web browser 
5 and a web server, as described briefly above with reference to Figure 4. This 

transaction is intended to provide merchants with the ability to reverse an erroneous 
transaction rather than to provide a refund to an unsatisfied end-user. 

Communications . 

10 Referring again to Figure 2, the connection between the payment system 

(processor 40) and the customer can be a Frame Relay network 1 14 or some other 
secure link, 116 in a presently preferred embodiment, although various 
communications hardware and protocols can be used. The communications protocol 
over which the transaction message will be transmitted from the payment system to 

15 the customer can be, for example, TCP/IP. The customer may implement any 

mechanism qualified to receive and respond to a TCP/IP message including a TCP/IP 
server side socket. 

Processing the Transaction at the Customer Processor 
20 Each transaction type is processed in a different way by the customer 

processor. Once the transaction type is identified, the processing that is likely to 
occur at the customer processor is described below. 

!■ Account Loading. Lookup the cardholder's account based on the 
customer account number. Perform validation checks. Add the payment amount to 
25 the account balance. Log the transaction. Respond to payment processor. 

2 - Account Validation. Lookup the cardholder's account based on the 
customer account number. Log the transaction. Respond to the payment processor. 

3 - Load Reversal. Lookup the cardholder's account based on the 
customer account number. Perform validation checks. This will include the 

30 verification that the cardholder's account balance is at least the value to be subtracted 
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from the balance. Subtract the amount of the previously processed transaction from 
the account balance. Log the transaction. Respond to the payment processor. 

Batch Processing . 

5 The payment system can be programmed to support batch processing. In a 

batch processing system, the customer will have available only a subset of the 
functionality that was described above. The following limitations can be expected in 
a batch environment: 

1. Delayed load transactions . As is the asynchronous nature of batch 
10 processing, any updates to the end-user account balance will experience a delay. 

2. No account validation . The effectiveness of the account validation 
transaction type is eliminated in a batch processing environment. Therefore, this 
transaction type will be unavailable. 

3. Limited load reversal transactions . It is a requirement of the load 
15 reversal transaction type that the end-user have an account balance of at least the 

amount to be reversed. This cannot be verified in a batch environment. 

Nonetheless, many of the essential advantages of the present invention can still 
be achieved with a batch processing arrangement. 

20 Settlement and Clearing . 

Figure 5 illustrates clearing and settlement processing according to the present 
invention. As described earlier, a card user 20 makes a cash payment to a merchant 
30 at a point-of-sale, and the merchant subsequently deposits the cash into the 
merchant's bank account 38. The payment transaction is logged in the payment 

25 processor 40 database (not shown). At the end of the processing day, the processor 
aggregates all of the loading (payment) transactions for the day based on merchant 
and batches them into a file. This function is carried out by the payment financial 
clearing and settlement services application 80, which may be implemented in 
software as a part of the processor system. This debit batch file 82 is submitted to the 

30 automated clearing house (ACH) Gateway 130 for processing. The ACH Gateway 
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130 in turns transmit this information to the federal reserve which in turn debits funds 
Q^ y from the merchant's bank account 38 and in turn credits the funds to the -re charge t er 

the pre-payment processor's bank account 140. Thus, the payment processor system 
performs various accounting functions and provide a clearing data that enables the 
5 settlement process to occur via the electronic transfer of funds from merchant bank 
accounts to the pre-payment processor bank accounts. Once the payment processor 
reconciles these transfers with transaction activities records to ensure that accurate 
funds were secured, funds are then forwarded onto the bank accounts of the 
corresponding customers. Several days may elapse between transaction activity and 
10 the actual transfer of funds into the customer's bank account, in which time the 
41 processing and reconciliation will occur. Periodic statements summarizing daily 

Lj | activity and associating that activity with subsequent fund transfers can be prepared 

1J by the processor and provided to the customers and merchants. 

15 Reporting Functions . 

f|j Figure 6 illustrates these reporting activities and a presently preferred 

embodiment. Referring to Figure 6, the payment reporting services 82 provide a 

□ daily activity summary to the POS merchant 30, and can also provide periodic, for 

example monthly, activity and financial summary information. Second, a payment 
20 reporting services provide daily activities summaries to its customer, for example the 
Wireless Carrier 110, and can also provide periodic activity and financial summaries. 
Finally, as illustrated in Fig. 6, reporting services 82 can provide periodic activity 
summaries to the wireless carriers prepaid platform vendor 112. 


25 Card Production and Management Services . 

Figure 7 illustrates the card production and management services. 
It will be obvious to those having skill in the art that many changes may be 
made to the details of the above-described embodiment of this invention without 
departing from the underlying principles thereof. The scope of the present invention 
30 should, therefore, be determined only by the following claims. 


